A structured query language (SQL) database model depends on tabular relationships in a relational database. NoSQL, which stands for “not only” SQL, refers to an approach for storing and retrieving data that does not use the SQL model. A NoSQL model may use key-value pairs in entities in a table storage that is optimized for retrieval and appending. Optimizing for one action may cause other actions to have sub-optimal performance. A key-value store allows data to be stored in a schema-less way in, for example, an object (e.g., binary large object (BLOB)). Table storage systems may be built on a BLOB and NoSQL framework. Like all data structures and organizations, a table storage system may work well for one type of operation but may not work as well for another type of operation.
A table storage system may store large amounts of data using a NoSQL database. The data may be, for example, unstructured data. The data may also be, for example, structured but non-relational data. A table storage system may be optimized for storing structured, non-relational data. A table storage system may store tables. A table may be considered to be a collection of entities. An entity corresponds roughly to a schema-less database record. A table can store different entities with different sets of properties. One property may be a partition key that facilitates grouping items into partitions or collections. A table may have multiple “partitions”, where a partition is defined as entities that have the same value for their partition key. Within a partition there may be different entities with different sets of properties. An entity may be considered to be a set of properties. In an object-oriented system, an entity may map to an object using, for example, a custom class. Adding an entity to a table may involve creating a class that defines the properties (e.g., name-value pairs) of the entity. A property may be defined as a name-value pair. A table may impose no schema requirement on an entity, even though an entity may have a partition key and a row key. The row key may be a unique identifier for an entity in a partition.
Different types of queries may seek different types of data from a table. For example, a first query may seek to retrieve all entities in a partition while a second query may seek to retrieve only some entities in a partition. One query may seek data about people with a last name “Smith” and then a subsequent query on the set of entities returned by the previous query may seek data about the people named Smith whose first name comes before “John.” Another query may get data about all the people with a certain partition key (e.g., last name “Smith”) and a certain row key (e.g., first name “John”). The table-entity-property organization for partitions with partition keys may optimize certain operations but may be challenged to support other operations. For example, filtering a partition on a specific field (e.g., property name) other than the partition key or row key may be a challenge.